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1.0  INTRODUCTION 

J 

This  Defense  Data  Network  (DDN)  subscriber  security  guide 
describes  the  security  architecture  now  being  implemented  for  the 
DDN.  The  architecture  will  be  used  until  around  1987  when  improved 
security  devices  are  expected  to  be  available.  The  guide  describes 
how  the  architecture  will  then  evolve.  The  guide  assumes  that  the 
reader  is  acquainted,  at  least  regarding  terminology,  with  the 
Defense  Data  Network  Program  Plan  as  revised  in  May  1982  [DDN82] , 
herein  called~-"the  PlaET"^^ Material  is  incorporated  in  this  guide  by 
reference  to  the  Plan.  -“V 

l‘l  Back&y9v.pd 

This  guide  supersedes  Section  3.3  of  the  Plan,  "Security  and 
Privacy  Approach."  That  section  sketches  a  network  security  architec¬ 
ture  that  depends  primarily  on  two  elements:  (1)  link  encryption  on 
the  trunks  and  (2)  end-to-end  encryption  (E  )  to  create  logical  sub¬ 
networks  that  separate  subscriber  groups.  The  Plan  assumes  that  all 
encryption  is  military  grade  (the  KG-84)  and  that  the  DDN  has  a  sin¬ 
gle,  optimized  backbone  network  of  switches  and  trunks. 

After  studying  the  Plan,  the  Deputy  Under  Secretary  of  Defense 
for  Communications,  Command,  Control,  and  Intelligence  requested  a 
review  of  some  architectural  options  (Lath82] .  One  class  of  options 
used  commercial  grade  encryption,  the  Data  Encryption  Standard  (DES) 
[FIPS46],  for  unclassified  data.  Another  involved  physically  parti¬ 
tioning  the  DDN  into  classified  and  unclassified  segments,  with  pro¬ 
vision  for  sharing  resources  in  a  crisis.  To  perform  the  review,  an 
ad  hoc  working  group  of  DCA,  NSA,  and  contractor  (BBN,  MITRE,  and 
SDC)  personnel  met  through  the  summer  of  1982.  It  defined  and 
analyzed  the  options  with  regard  to  performance,  cost,  technical 
risk,  schedule,  and  security  risk. 
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This  guide  describes  the  architecture  chosen  from  among  the 
several  options  documented  in  [DCA82a,  DCA82b,  NSA82a,  and  HSA82b] . 
Those  documents  refer  to  the  chosen  architecture  as  "option  2.2,  with 
[Internet  Private  Line  Interface  devices]  IPLIs  on  the  SECRET  users, 
and  without  re implementation  of  either  switch  or  monitoring  center." 

This  guide  describes  the  security  architecture  to  which  the  DDN 

will  evolve  prior  to  the  introduction  of  multilevel  secure  hosts, 
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which  will  use  the  next,  post-IPLI  generation  of  E  devices,  called 
BLACKER  devices.  The  planned  stages  of  the  evolution  are  described 
in  Section  6.  The  BLACKER  devices  will  permit  interconnection  of 
trusted  hosts  across  security  levels.  To  complete  the  definition  of 
BLACKER  requirements  for  the  DDN,  a  study  has  already  begun  [DCA83c]. 

Implementation  of  the  chosen  architecture  requires  a  number  of 
tasks.  These  have  been  incorporated  in  the  DDN  Management  Engineer¬ 
ing  Plan  [DCA83a].  Additional  details  are  contained  in  the  Defense 
Pat£  Network  Subscriber  Interface  Guide  [DCA83b] . 

1.2  S£gui;itJ.Oyeryigy 

Figure  1  shows  the  DDN  split  into  two  separate  backbone  networks 
called  segments,  one  classified  and  one  not,  that  are  connected  by 
gates.  (The  term  "gate"  is  deliberately  chosen  to  be  different  from 
the  term  "gateway"  that  is  used  in  internetworking.) 

1  Topology.  The  segments  are  optimized  independently  of  each 
other,  one  for  classified  subscribers  and  the  other  for 
unclassified.  The  segments  are  linked  at  several  points  by 
gates.  Each  gate  is  attached  to  one  switch  in  each  of  the 
segments.  Any  switch  has  at  most  one  attached  gate. 

The  segments  are  assumed  to  be  physically  connected  by  the 
gates  at  all  times.  When  allowed  by  the  gate  logic,  data 
from  the  classified  segment  can  flow  into  the  unclassified 
segment,  through  the  unclassified  segment,  and  back  to  the 
classified  segment.  However,  traffic  originated  in  the 
unclassified  segment  never  can  flow  through  the  classified 
segment . 
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Classified  I  | 

Community  “X”  |  Classified  Segment  I  Unclassified  Segment 


Classified  feH;:;:;!  "Restricted 


A  gate  acts  like  an  IPLI  with  a  modified  plaintext  side.  On 
its  plaintext  side  it  attaches  to  a  switch  in  the  classified 
segment,  and  on  its  cyphertext  side  to  one  i^  the  unclassi¬ 
fied  segment.  It  provides  gate-to-gate  E  for  classified 
packets  that  leave  the  classified  segment  to  flow  through 
the  unclassified  segment.  The  two  segments  are  always  con¬ 
nected  to  allow  this  flow. 

2  Switch  security.  All  switches  in  the  classified  segment  and 
all  OCONUS  (outside  the  continental  United  States)  switches 
in  the  unclassified  segment  reside  in  facilities  protected 
to  the  SECRET  level.  In  the  rest  of  the  unclassified  seg¬ 
ment,  access  to  switches  is  "restricted"  [Lath  82]  but  not 
necessarily  at  the  SECRET  level. 

3  Traffic  flow  security.  Trunks  and  access  lines  of  the  clas¬ 
sified  segment  are  link  encrypted  with  KG-84s.  OCONUS- 
OCONUS  and  CONUS-OCONUS  trunks  of  the  unclassified  segment 
use  KG-84s,  but  the  rest  use  the  DES.  Section  2.0  defines 
what  DES  means  in  the  DDN  context  in  terms  of  allowable 
equipment  and  procedures. 

4  Subscriber  connection.  Each  classified  subscriber  in  the 
segmented  DDN  connects  to  the  network  only  through  an  IPLI 
that  incorporates  a  KG-84.  But  the  DDN  neither  provides  nor 
requires  EJ  for  unclassified  subscribers,  and  they  may  con¬ 
nect  directly  to  a  switch. 

5  Gate  Security.  Each  gate  is  located  in  a  facility  cleared 
to  the  SECRET  level.  The  same  facility  houses  the  attached 
classified  switch.  Traffic  passing  through  a  gate  from  the 
classified  to  the  unclassified  segment  is  superencrypted  by 
a  KG-84  that  is  part  of  the  gate. 

Additional  details  follow  in  this  guide  or  are  available  in  the 
references . 

1 .3  Section  Summaries 

The  rest  o^  This  guide  describes  the  DDN  security  architecture 
in  greater  detail.  Section  2  describes  the  cryptographic  security 
features  and  points  out  where  subscribers  have  options  regarding 
encryption.  Section  3  describes  hardware  security,  particularly  pro¬ 
tection  against  compromising  emanations.  Section  4  describes  the 


software  features  of  the  DDN  that  are  trusted  to  operate  correctly, 
including  features  of  the  subscribers'  hosts.  Section  5  describes 
requirements  for  physical  and  personnel  security  and  other  opera¬ 
tional  matters.  Section  6  describes  how  the  security  architecture 
will  evolve.  During  the  1982  summer  review,  the  architecture  of  the 
integrated  DDN  was  defined  in  sufficient  detail  to  permit  reasonable 
assurance  that  it  is  adequate  to  meet  mid-range  needs  of  the  DDN,  and 
to  provide  the  basis  for  reasonable  transitions  to  a  longer  range  DDN 
architecture  with  multi-level  secure  hosts  and  BlACRER-style  E  . 
However,  a  number  of  areas  continue  to  be  studied. 


2.0  CRYPTOGRAPHIC  SECURITY  FEATURES 

This  section  describes  the  cryptographic  security  provided  by 
the  DDN  to  its  subscribers.  All  classified  data  and  related  network 
control  functions  are  protected  by  military-grade  encryption,  the 
KG-84,  for  which  the  required  mode  of  operation  in  the  DDN  is 
described  in  Appendix  A.  For  unclassified  data  and  related  control 
functions,  the  the  DDN  uses  commercial-grade  encryption,  the  DES. 

•  Data  Encryption  Standard.  In  the  DDN,  "DES"  means  equipment 
that  conforms  to  [FIPS46],  [FIPS81],  [FS1027],  and  any  other 
applicable  rules,  such  as  pending  [FS1025]  and  [FS1026].  In 
particular,  it  also  means  equipment  certified  relative  to 
FIPS46  by  NBS,  and  endorsed  relative  to  FS1027  by  NSA.  This 
meaning  applies  to  trunk  encryption  in  the  unclassified  seg¬ 
ment,  to  unclassified  subscriber  access  line  encryption,  and 
to  other  uses  that  are  subscriber  options. 

Figure  2  shows  the  security  architecture  in  more  detail.  DDN 
user  devices  include  host  computers,  network  access  components  (NACs) 
—  including  terminal  access  controllers  (TACs),  host  front-end  pro¬ 
cessors  (HFEPs),  and  terminal  emulation  processors  (TEPs)  —  gateways 
to  neighbor  networks,  and  other  devices.  This  paper  refers  to  all 
these  user  devices  as  hosts  or  subscribers.  All  classified  hosts 
connect  to  the  DDN  through  IPLIs.  Remote  access  lines  for  classified 
host 8  must  be  link  encrypted. 

Portions  of  the  DDN's  unclassified  segment  that  are  OCONUS,  such 
as  the  expanded  Movements  Information  Network  (MINET)  in  Europe  and 
DDN  assets  in  the  Pacific,  use  KG-84s  on  their  OCONUS-OCONUS 
interswitch  trunks  and  on  the  CONUS-OCONUS  interswitch  trunks  that 
connect  those  portions  to  the  CONUS.  All  such  KG-protected  trunks 
connect  on  both  ends  to  switches  protected  to  the  SECRET  level.  All 
remaining  switches  of  the  unclassified  segment  that  are  in  the  CONUS, 
that  is,  all  unclassified  switches  that  do  not  connect  directly  to  an 
OCONUS  switch,  reside  in  at  least  "restricted"  locations.  All 
unclassified  trunks  connecting  two  CONUS  switches  are  encrypted  with 


the  DES.  An  unclassified  remote  host  access  line  generally  vill  not 
be  encrypted,  but  it  may  be  link  encrypted  with  the  DES,  or  with  KG- 
84s  if  the  line  connects  to  a  switch  in  a  SECRET  facility,  if  the 
subscriber  wishes  to  provide  that  protection. 

Each  segment  has  a  system  monitoring  center  (SMC)  and  may  have 
one  or  more  regional  monitoring  centers  (RMCs).  In  addition,  there 
are  five  community  of  interest  monitoring  centers  (COI  MCs). 

The  Flan  lists  five  classified  COIb  and  one  unclassified  COI. 

Each  classified  COI  has  a  COI  MC  that  connects  to  the  DDN  through  an 

IPLI  just  like  any  other  classified  host.  The  unclassified  COI  does 
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not  have  a  COI  MC,  because  the  unclassified  hosts  do  not  use  E  and, 
therefore,  can  communicate  with  the  S/&  MCs  in  the  unclassified  seg¬ 
ment. 

Figure  3  shows  the  number  of  sites  serviced  by  the  DDN  for  each 
COI  and  the  number  of  IFLIs  required.  The  estimates  assume  the  larg¬ 
est  probable  number  of  subscribers. 

Figure  3 

Estimated  IPLI  Quantities 


ENCRYPTION  COMMUNITY 

IPLI  SITES 

REQUIRED  IPLI s 

SACDIN 

25 

60 

SCI 

70 

100 

Top  Secret 

70 

100 

Secret 

200 

500 

Gates 

20 

30 

Total 


475 


970 


3.0  HARDWARE  SECURITY  FEATURES 


This  section  discusses  security  requirements  for  DDN  hardware 
components. 

3.1 

Proposed  DDN  hardware  is  not  now  manufactured  in  secure  facili¬ 
ties.  Security  clearances  are  not  now  required  for  personnel 
involved  in  the  construction  of  any  components  except  RGs  and  IPLIs. 
Integrated  circuit  components  of  all  DDN  equipment  may  have  various 
countries  of  origin.  IPLIs  and  NACs  are  entirely  assembled  in  the 
U.S.,  but  assembly  of  some  printed  circuit  boards  for  the  C-30 
switches  and  C-70  MCs  is  currently  done  in  Hong  Kong  and  the  U.S., 
with  final  assembly  in  the  U.S.  Cryptographic  equipment  is  con¬ 
structed  in  accordance  with  NSA  practices.  No  assumptions  are  made 
about  the  location  of  construction  of  other  DDN  components  (sub¬ 
scriber  hosts  and  terminals,  modems,  statistical  multiplexers, 
transmission  media,  etc.). 

3.2  Sgqyrity-Reigtg4  jjtfdmft  ggputtet 

Single-bit  error  correcting  memory  is  used  in  the  switches,  MCs, 
and  NACs.  Security-related  hardware  features  of  the  IPLI  are 
described  in  [BBN4974A,  BBN4975] ,  particularly  in  Section  7.2  of  the 
latter.  No  other  security-related  hardware  features  are  assumed. 

3.3  Hardware  Confieuration  Control 

The  SMC s  for  the  DDN  backbone,  and  the  COI  MCs  for  the  user-side 
subnets,  maintain  (for  all  system  components)  descriptions  of 
currently  installed  items  and  their  configuration.  The  level  of 
detail  varies  depending  on  the  item.  Vendor  and  Life  Cycle  Manager 
maintenance  records  will  identify  system  components  down  to  indivi¬ 
dual  "bit,  part,  and  piece"  level. 


*.  \ 


3.4  MsMXioss  Sfifiutita 

DDN  equipment  is  TEMPEST  compliant  in  accordance  with  NACSIM 
5100A  at  1  meter.  Installation  is  compliant  with  NACSEM  5203  (30 
June  1982).  Testing  is  according  to  the  current  version  of  DCA  cir¬ 
cular  370-D195-2.  These  requirements  apply  to  the  following  equip¬ 
ment,  which  is  described  in  the  indicated  sections  of  the  Plan.  A 
means  that  the  equipment  may  not  be  TEMPEST,  but  is  instead  pro¬ 
tected  by  the  enclosing  facility. 

EQUIPMENT  NAME  PLAN  SECTION 


Switching  Node  2.1 

Internet  Private  Line  Interface  2.2 

Mini-TAC  (Terminal  Access  Controller)  2.3 

Statistical  Multiplexor  2.4 

Host  Interface  Devices  as  follows: 

-  Host  Front-End  Processor  (HFEP)  2.5.2 

-  Terminal  Emulation  Processor  (TEP)  2.5.3 

Network  Monitoring  Center  (MC)  Equipment  2.6 

*  Test  and  Development  Facilities  2.7 

Cryptographic  Equipment  2.8 

Automatic  Line  Restoral  Option  2.11 

Patch  and  Test  Facilities  2.12 

Uninterruptible  Power  Supplies  2.13 

Power  and  Environment  Monitor  2.14 

Mobile  Reconstitution  Van  2.15 

-  Equipment  yes . 

-  Van  no . 
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4.0  SOFTWARE  SECURITY  FEATURES 


This  section  describes  DDN  features  that  are  trusted  to  operate 
correctly.  Different  features  require  different  levels  of  trust 
because  of  the  differing  levels  of  sensitivity  of  their  operation. 
The  security  evaluation  criteria  needed  to  achieve  levels  of  trust 
appropriate  to  DDN  equipment  are  defined  in  Figure  4. 

Figure  4 

Definition  of  Security  Evaluation  Levels 


LEVEL  0.  COMMON  COMMERCIAL  PRACTICE. 

No  special  requirements  for  development  or  maintenance. 


LEVEL  1. 


LEVEL  2. 


STRICT  CONFIGURATION  CONTROL. 

No  special  requirements  for  initial  system  development. 
After  that,  strict  hardvare/softvare  configuration  control. 
All  maintenance  personnel  have  security  clearances. 

System  documentation  sufficient  for  minimum  security  review 
Experienced  programmer  can  understand  with  effort. 

Includes  software  module  and  interface  descriptions. 

Two  person-months  of  penetration  testing. 

STRUCTURED  SOFTWARE  DEVELOPMENT.  All  of  level  1,  plus: 

All  software  developed  (or  redeveloped,  if  necessary)  using 
structured  programming  methods. 

Documentation  includes  a  descriptive,  English  top  level 
specification  (DTLS)  of  security  relevant  parts  of  system. 
Experienced  programmer  can  understand  with  minor  effort. 
Includes  detailed  descriptions  and  diagrams  for  each  module 
Penetration  testing  effort  increased  to  four  person-months . 


LEVEL  3.  MODELED  SECURITY.  All  of  level  2,  plus: 

—  Documentation  includes  description  of  formal  model  used  as 
basis  of  security  design. 

Model  informally  shown  to  be  consistent  and  to  satisfy  its 
axioms . 

DTLS  informally  shown  to  support  the  model. 

Experienced  programmer  can  understand  with  ease. 

—  Penetration  testing  effort  increased  to  six  person-months. 


Figure  5  shows  the  level  of  security  evaluation  criteria  that  is 
met  by  each  major  DDN  system  element. 

Figure  5 

Required  Security  Evaluation  Levels 


Switches  and  Monitoring  Centers 
Internet  Private  Line  Interfaces 
Network  Access  Components 
Subscriber  Hosts 
Inter-segment  Gates 
Other  System  Elements 


CLASSIFIED 

SEGMENT 


0-3 


UNCLASSIFIED 

SEGMENT 


Not  Applicable 


0-3 


The  levels  are  shown  separately  for  each  segment  because  they  differ 
for  the  switches  and  NACs.  For  example,  a  switch  has  level  1  for  the 
classified  segment  and  0  for  the  unclassified.  The  unclassified  seg¬ 
ment  will  receive  the  same  hardware  and  software  as  the  classified, 
so  it  will  be  at  level  1  when  shipped  or  installed.  However,  the 
switch  is  assumed  to  be  trusted  only  to  level  0  on  a  continuing 
basis  because  the  environment  may  not  guarantee  its  integrity. 


Nearly  all  switch  software  is  related  to  some  aspect  of  secure 
network  operation. 

1  Integrity  check.  A  Data  Link  layer  checksum  is  computed  and 
sent  with  all  switch  outputs  and  computed  and  compared  for 
all  switch  inputs,  except  1822  Local  Host  inputs  [DCA83b]. 
A  switch  periodically  checksums  all  of  its  programs  and 
tables.  In  addition,  before  a  switch  puts  into  operation 
software  received  from  a  MC,  from  a  neighbor  switch,  or  from 
a  manual  load,  it  checksums  the  software.  These  checks  are 
performed  by  software. 


Control  message  authentication  and  execution.  A  switch  exe¬ 
cutes  control  messages  sent  from  a  MC,  validating  them  as 
follows:  (1)  Header  information  is  checked  for  a  valid  MC 
logical  source  address.  (2)  Control  message  sequence 
numbers  are  checked  with  a  windowing  algorithm  to  assure 
they  are  increasing. 

Neighbor  reload.  The  process  by  which  a  switch  receives  a 
reload  of  software  from  a  neighbor  is  described  in  [BBN89] . 
A  reload  is  accepted  only  from  a  switch  in  the  same  segment. 
A  switch  validates  neighbor  reloads  in  the  same  way  that  it 
validates  MC  messages. 

Correct  destination.  Information  is  passed  only  to  the  des¬ 
tination  for  which  it  is  intended.  Section  3.2.5  of  the 
Flan  discusses  the  possibility  of  misdelivery  due  to  errors 
on  host  access  lines  or  on  trunks.  Other  possible  causes  of 
misdelivery  are  switch  software  errors,  switch  hardware 
errors,  intelligent  attacks  on  the  trunks,  and  host-induced 
addressing  errors. 

Community  of  interest.  Section  3.3.3  of  the  Plan  defines 
and  discusses  COIs.  In  brief,  the  DDN  can  separate  COIs 
either  by  encryption,  by  controlled  routing,  or  by  both.  In 
the  first  case,  a  COI  is  called  a  "crypto  community”  and,  in 
the  second,  a  logical  subnet  or  "routing  community." 

A  DDN  crypto  community  includes  as  many  as  1024  unclassified 
subscribers  or  512  classified  subscribers.  The  DDN 
separates  crypto  communities  by  two  means.  In  the  switches 
aijd  on  the  trunks,  it  does  it  with  E  .  At  the  locations  of 
E  ,  the  IPLIs,  it  does  it  with  key  control  and  software  con¬ 
trol. 

There  can  be  16  routing  communities,  and  they  can  overlap. 
The  DDN  separates  routing  communities  by  using  software  at 
the  source  and  destination  switch  of  each  message.  A  source 
switch  marks  packets  from  a  subscriber  with  the  valid  rout¬ 
ing  communities  of  the  subscriber.  Before  delivery,  a  des¬ 
tination  switch  verifies  that  the  destination  subscriber  is 
a  member  of  a  routing  community  specified  by  the  source 
switch.  This  is  done  by  comparing  a  routing  COI  marking  in 
the  header  of  each  message  sent  from  a  subscriber  to  a 
switch,  or  vice  versa,  against  a  table  in  the  switch.  The 


SMC  is  responsible  for  the  switch  table. 
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Precedence.  Processing  of  traffic  is  based  on  the  pre¬ 
cedence  level. 

7  Line  up /down  protocol.  Communications  links  are  put  into 
and  taken  out  of  service  in  accordance  with  the  current  cri¬ 
teria.  The  basic  criteria  are  described  in  [BBN89] . 
Specific  parameter  settings  may  vary  based  on  line  experi¬ 
ence. 

8  Event  reporting.  A  switch  reports  anomalous  events,  and 
periodic  status  information,  including  traffic  statistics, 
to  a  monitoring  center  and  only  to  a  monitoring  center. 

4.2  Internet  Private  Line  Interface 

IPLI  operation  is  described  in  [BBNDCA,  BBN4968,  BBN4968B, 

BBH4974A,  and  BBN4975],  particularly  the  latter  two.  An  IPLI  con¬ 
trols  the  flow  of  information  on  its  symmetric  ciphertext-plaintext 
bypass,  executes  and  safeguards  control  messages  sent  to  it,  manages 
its  address  and  configuration  tables,  manages  cryptovariables,  and 
correctly  controls  its  cryptor.  An  IPLI  translates  destination 
addresses  from  the  plaintext  to  the  ciphertext  side,  without  corrupt¬ 
ing  either  addresses  or  any  other  IP  header  data  fields.  The  cipher- 
text  side  of  an  IPLI  implements  the  network  access  (host-switch)  pro¬ 
tocol,  and  the  precedence  level  of  a  message  sent  to  a  switch  by  the 
ciphertext  side  of  an  IPLI  does  not  exceed  the  maximum  precedence 
level  that  is  assigned  to  the  IPLI  by  its  COI  MC.  Anomalous  events 
and  periodic  status  information,  including  traffic  statistics,  are 
reported  to  the  proper  monitoring  center. 

The  plaintext  side  (1)  rejects  a  DCA-bound  Internet  Protocol 
(IP)  [DDN83b]  datagram  if  the  destination  address  is  not  listed  in 
the  plaintext  address  table,  and  (2),  for  IP  datagrams  received  from 
the  DDN,  performs  the  normal  IP  gateway  functions.  The  ciphertext 
side  checks  (1)  the  IP  source  address  received  from  the  switch  to  see 
that  the  address  is  in  that  IPLI's  destination  address  table  and  (2) 


the  validity  o£  the  destination  index  received  from  the  plaintext 
side. 


The  plaintext  side  verifies  the  checksum  in  the  header  of  IP 
datagrams  bound  either  to  or  from  the  ciphertext  side.  The  cipher- 
text  side  verifies  the  checksum  for  traffic  from  the  DDN  and  inserts 
the  checksum  for  traffic  to  the  DDN.  On  both  sides,  when  an  IPLI 
finds  an  incorrect  checksum,  it  discards  the  datagram  and  reports  the 
error  to  a  MC. 

4.3  Network  Access  Component 

Except  for  IPLIs,  the  NACs  are  the  only  DDN  components  that  con¬ 
tain  classified  data  from  a  subscriber. 

1  Access  control.  Each  NAC  operates  at  a  single,  system  high 
security  level.  A  HFEP  or  TEP  does  not  control  access 
either  to  its  host  or  to  the  DDN:  each  host  is  expected  to 
perform  the  access  control  function.  A  mini-TAC  has  only  a 
single  controlled  resource,  namely  network  access.  The  DDN 
provides  both  hardwire  and  dial-up  access  to  mini-TACs. 
Hard-wired  subscribers,  which  include  all  classified  sub¬ 
scribers  to  mini-TACs,  are  identified  in  the  mini-TAC,  and 
are  not  required  to  log  into  the  mini-TAC  with  a  password. 
Users  of  such  terminals  are  still  required  to  log  into  des¬ 
tination  hosts.  All  dial-up  subscribers  are  unclassified. 
Their  access  to  a  mini-TAC  is  controlled  by  an  account 
number  and  password. 

2  Precedence  and  preemption.  A  mini-TAC  associates  a  pre¬ 
cedence  with  each  terminal,  and  checks  that  the  precedence 
used  does  not  exceed  the  associated  precedence.  A  mini-TAC 
services  terminals  according  to  their  precedence.  A  mini- 
TAC  has  sufficient  resources  to  support  active  terminals  on 
all  terminal  ports  simultaneously,  so  it  never  needs  to  ini¬ 
tiate  a  preemption.  However,  it  supports  preemption  of  con¬ 
nections  initiated  from  the  destination  (when  the  procedures 
for  doing  so  are  defined).  Procedures  for  a  HFEP  or  TEP  are 
the  same  as  for  a  mini-TAC,  except  that  preemption  may  be 
initiated  by  a  host  request,  or  HFEP  independent  action,  as 
well  as  by  remote  network  request. 
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3  Integrity  checking.  Duplicate  message  detection,  out-of¬ 
sequence  message  detection  (and  resequencing),  and  message 
alteration  detection  are  provided  by  the  Transmission  Con¬ 
trol  Protocol  (TCP)  implemented  in  the  mini-TAC  [DCA83b] . 
Hosts  may  obtain  three  levels  of  service  from  the  HFEP:  TCP 
in  the  Transport  layer,  IP  in  the  Internet  layer,  or  DDN 
protocol  in  the  Network  layer  [DCA83b] .  Integrity  checking 
for  TCP  users  is  the  same  as  for  the  mini-TAC.  Internet  and 
Network  layer  protocol  users  are  responsible  for  providing 
their  own  integrity  checks,  if  required.  A  TEP  provides  the 
same  integrity  checking  as  the  mini-TAC. 

4  Senarat ion  of  traffic.  A  NAC  maintains  separation  between 
streams  of  traffic,  such  as  for  the  separate  terminals  on  a 
mini-TAC,  and  does  not  alter  their  information.  A  mini-TAC 
does  not  deliver  data  to  the  wrong  terminal.  All  the  termi¬ 
nals  attached  to  a  given  mini-TAC,  or  all  the  ports  attached 
to  a  TEP,  operate  at  the  same  security  level. 

5  Audit  information.  A  mini-TAC,  and  other  NACs  where 
appropriate,  collects  a  limited  amount  of  audit  information 
(connection  times,  duration,  destination,  caller  identity 
for  dial-up  users,  and,  where  technically  feasible,  the  cal¬ 
ling  number  for  dial-up).  Audit  information  is  sent  only  to 
a  secure  COI  MC. 

4.4  Monitoring  Center 

Nearly  all  MC  software  is  related  to  some  aspect  of  secure  net¬ 
work  operation. 

1  Access  control.  A  MC  requires  a  userid/password  for  access 
to  it,  and  it  gives  either  monitor  or  monitor  and  control 
capabilities  to  the  user  based  on  the  userid.  (This  is  a 
partially  redundant  check,  since  access  to  terminals  capable 
of  logging  on  to  a  MC  is  restricted  to  authorized  person¬ 
nel.) 

2  Messages  and  software  sent .  A  MC  implements  (1)  down-line 
loading  of  software  for  switches  and  (2)  control  message 
protocols  for  switches.  A  MC  cooperates  in  the  integrity 
and  authenticity  checks  described  in  Section  4.1.  Each  MC 
has  a  standard  logical  source  address.  It  sequence  numbers 
the  messages  it  sends.  It  computes  and  appends  a  checksum 
for  software  modules.  A  MC  implements  control  message  pro¬ 
tocols  for  IPLIs  as  described  in  Section  4  of  [BBN4975]. 


3  Audit  information.  A  MC  requests,  collects,  and  retains  for 
a  limited  period,  events  reported  to  it  from  switches  (in 
the  case  of  the  SMC  and  &MC);  from  IPLIs  (SMC  and  RMC  on  the 
DDN  side,  COX  MCs  on  user  side  of  IPLI);  and  from  hosts  and 
HACs  (COI  MCs  only). 

4  MC  Initialization.  The  MCs  unambiguously  take  and  maintain 
control  of  network  resources  in  accordance  with  network  pol¬ 
icy. 

4.5  Subscriber  Host 

This  section  discusses  particular  features  of  subscriber  hosts 
that  are  trusted  to  operate  correctly. 

1  Access  control.  All  hosts,  whether  attached  directly  to  the 
user  side  of  an  IPLI  or  indirectly  through  a  user-side  net¬ 
work,  are  responsible  for  controlling  access  to  (1)  their 
own  user-side  network  and  (2)  the  DDN-side  backbone  network. 
All  DDN  subscriber  hosts  are  required  to  have  a 
userid/password  or  equivalent  level  of  control  before  grant¬ 
ing  access  to  or  from  the  DDN. 

2  Integrity  checking.  Hosts  that  have  HFEP  or  TEP  network 
connections  are  provided  a  TCP  level  of  integrity  checking. 
Other  hosts  are  expected  to  implement  the  degree  of 
integrity  checking  that  they  require  internally.  Normally 
this  would  be  via  implementation  of  TCP.  Hosts  that  require 
levels  of  integrity  checking  beyond  that  provided  by  TCP 
will  develop  their  own  procedures  to  establish  (or  re¬ 
establish)  integrity  to  the  required  level. 

3  Precedence  and  preemption.  Hosts  with  precedence  and 
preemption  requirements  will  implement  appropriate  facili¬ 
ties  to  make  use  of  the  precedence  and  preemption  services 
of  the  network.  The  nature  of  these  facilities  is  dependent 
on  the  type  of  network  interface.  Hosts  are  responsible  for 
correct  implementation. 

4.6  Inter-Segment  Gate 


A  gate  executes  control  messages  from  SMCs  in  both  the  classi¬ 
fied  and  unclassified  segments,  validating  these  control  messages  the 
same  way  as  the  switch,  as  described  in  Section  4.1.  However,  a  gate 
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accepts  no  software  changes  or  table  updates  from  any  MC;  a  gate  has 
fixed  software  and  tables. 

A  gate's  encryption  bypass  sends  the  information  necessary  to 
address  packets  sent  from  the  classified  to  the  unclassified  seg¬ 
ments.  A  gate's  key  update  protocol  permits  synchronized  update  of 
the  keys  in  all  the  gates.  The  protocol  is  the  same  as  that  used  in 
the  IPLI.  Anomalous  events,  periodic  status  information,  and  traffic 
statistics  are  reported  to  the  appropriate  monitoring  centers. 

4.7  Other  Network  Elements 

Network  elements  such  as  modems,  statistical  multiplexers,  patch 
and  test  facilities,  and  automated  equipment  associated  with 
transmission  media  are  expected  to  correctly  perform  their  functions. 

4.8  Software  Configuration  Control 

All  software  mentioned  above  except  for  Subscriber  Hosts  and 
Other  Network  Elements  is  controlled  using  the  UNIX-based  SCCS 
(Software  Configuration  Control  System).  Note  that  "strict 
hardware/software  configuration  management"  iB  required  by  level  2  as 
defined  in  Section  4.0.  Software  changes  are  only  made  subject  to 
government  approval.  This  control  begins  when  the  security  evalua¬ 
tion  begins  and  continues  throughout  the  network's  life.  This  con¬ 
trol  includes  physical  and  personnel  security  as  described  in  Section 
5. 


I 


18 


5.0  0TB  ER  SECURITY  FEATURES 


This  section  discusses  physical  and  personnel  security  and  some 
aspects  of  network  operation. 

5 . 1  Physical  and  Personae.  ktmUV 

The  physical  soo  par .  security  provided  in  the  DDN  is  as 

follows-  First  ,  m  the  -ed  segment: 

1  Equipment  that  s.as  lass  if  led  plaintext  is  protected  to 

the  level  appro i»t  «•  for  that  traffic.  That  is,  all  the 
equipment  in  a  CPI  -  subscriber  hosts  and  terminals,  NACs, 
IPIIs,  the  CO  I  me,  any  unencrypted  links,  and  any  KGs  on 
links  directly  connecting  these  elements  --  is  protected  at 
least  to  the  level  of  its  CO I .  In  Figure  2,  this  is  the 
equipment  to  the  left  of  the  heavy,  vertical  dashed  line. 

2  Equipment  that  does  not  contain  classified  COI  plaintext  is 
protected  at  least  to  the  SECRET  level.  This  includes 
switches,  other  HCs  (system,  regional,  and  mobile),  and  any 
KGs  on  links  directly  connecting  these  elements  to  each 
other  or  to  IPLIs.  In  Figure  2,  this  is  the  equipment 
between  tbe  heavy  dashed  line  and  the  double  dashed  line. 
It  also  includes  the  software  and  hardware  configuration 
control  facilities.  The  facilities  housing  these  elements 
are  physically  protected  to  handle  at  least  SECRET  material 
in  accordance  with  the  requirements  of  the  service  or  agency 
responsible  for  the  protection  of  each  facility.  Personnel 
at  these  locations  are  required  to  have  at  least  SECRET 
level  clearances. 

3  No  specific  protection  requirements  exist  for  modems  and 
transmission  media  making  up  the  trunks  or  link  encrypted 
access  lines.  Unconstrained  access  to  such  media  must  be 
assumed. 

Second,  in  the  unclassified  segment: 

1  All  0C0NUS  switches,  other  switches  directly  attached  to 
0C0NUS  switches,  and  associated  KG-84  link  encryption  equip¬ 
ment  will  receive  the  same  SECRET  level  protection  as  the 
equipment  in  the  classified  segment. 

2  All  other  switches  and  the  DES  encryption  equipment  are  in 
locations  protected  with  restricted  access.  "Restricted 


access"  means  that  only  authorized  personnel  are  permitted 
access  to  the  area  in  which  the  equipment  is  located. 
Authorized  personnel  are  those  who  require  access  to  the 
area  in  which  the  equipment  is  located  in  order  to  perform 
their  duties,  and  personnel  accompanied  by  such  personnel. 
A  variety  of  methods  may  be  employed  to  restrict  access. 

Examples  of  a  minimum  level  of  acceptable  access  restriction 
would  be  locked  access  doors  with  card  or  keys  required  for 
entry,  or  guarded  access  doors  with  entry  based  on  identifi¬ 
cation  such  as  a  special  badge  or  normal  personal  identifi¬ 
cation  plus  presence  on  an  access  list  to  the  (unarmed) 
guard.  Personnel  with  access  to  this  area  are  considered 
ADP.II  critical  personnel  as  defined  by  [OPM78] ,  and  they 
meet  the  requirements  for  such  personnel. 

DES  link  encryption  keying  material  is  stored  (when  not  in 
the  DES  device,  which  itself  is  protected  [FS1027])  in 
secure  containers  (i.e.,  containers  with  a  lock)  to  which  no 
more  than  ten  people  have  keys  or  combinations.  Personnel 
with  such  access  are  considered  ADP-Z  critical  personnel  as 
defined  by  [OPM78],  and  meet  the  requirements  for  such  per¬ 
sonnel. 


3  No  specific  protection  is  required  for  transmission  media. 

4  No  restrictions  are  placed  on  the  locations  of  unclassified 
access  area  equipment. 

Third,  the  inter-segment  gates  and  associated  link  cryptographic 
equipment  are  located  in  areas  protected  to  the  SECRET  level. 

5.2  Network  Operation 

The  DDN  operates  as  described  in  [DGA82a].  Specific  details  of 
the  operation  of  switches,  IPLIs,  and  MCs  are  described  in  [BBN89], 
[BBN4975],  and  [BBN4823].  Each  segment  has  separate  monitoring 
facilities.  In  the  classified  segment,  there  are  S/R  MCs,  mobile 
MCs,  and,  for  each  separately  keyed  IPLI  community,  a  COI  MC.  In  the 
unclassified  segment,  the  S/R  MCs  also  perform  the  unclassified  COI 
MC  functions,  and  there  are  no  mobile  MCs  (although  those  of  the 
classified  segment  could  be  used  if  required).  Control  of  both  sides 
of  a  gate  is  the  responsibility  of  the  classified  segment  S/R  MC,  but 


the  cyphertext  side  of  a  gate  responds  to  Internet  Control  Message 
Protocol  [DCA83b]  messages  that  appear  to  have  the  address  of  the 
unclassified  segment  S/R  MC. 

5.3  Rev  Management  for  Mobile  MCs 

A  mobile  MC  needs  cryptographic  keys  to  establish  conanunicat iona 
over  any  trunk  to  any  switch  in  the  MC's  zone  of  operations.  Each 
switch  location  has  keys  for  each  mobile  MC  with  which  the  switch 
might  establish  contact. 

A  mobile  MC  can  be  deployed  with  IPLI  keys  for  UNCLASSIFIED, 
SECRET,  and  TOP  SECRET  COIs,  if  it  is  appropriate  to  the  mobile  MC's 
mission.  Otherwise,  and  particularly  for  other  COIa,  a  mobile  MC 
must  collocate  with  a  community  member  and  obtain  the  COI  IPLI  key 
directly  from  the  member. 


6.0  EVOLUTION 


This  section  describes  the  stages  through  which  the  DDN  security 
architecture  will  evolve.  It  also  lists  areas  for  further  study  that 
are  related  to  the  evolution. 

6.1  Evolution  Stages 

The  planned  approach  to  evolving  the  DDN  is  to  develop  several 
physically  separate  networks  for  the  different  security  groupings  in 
the  DDN,  and  then  merge  the  networks  as  IPLIs,  gates,  and  BLACKER 
devices  become  available.  In  implementing  this  approach,  substantial 
flexibility  is  possible.  The  security  architecture  implementation 
can  parallel  the  four  network  integration  stages. 

1  The  first  stage,  based  on  the  initial,  prototype  IPLI 
development,  permits  integration  of  the  DODIIS  and  TOP 
SECRET  (WIN)  networks.  Concurrently,  on  the  unclassified 
segment,  DES  link  encryption,  and  access  control  for  dial-up 
TAC  and  mini-TAC  users,  will  be  established  as  soon  as  pos¬ 
sible. 

2  The  second  stage,  based  on  the  "Phase  2"  IPLI,  which  permits 
SECRET  hosts  to  run  on  an  unclassified  network,  will  also 
support  hosts  that  normally  run  unclassified  but  sometimes 
run  in  periods  processing  security  mode  at  the  SECRET  level. 

3  The  third  stage,  the  joining  of  the  TOP  SECRET/SI/SIOP  net¬ 
work  and  the  SECRET  network  will  be  accomplished  with  the 
"Phase  3"  IPLI,  which  will  support  TOP  SECRET  hosts  on  a 
SECRET  network.  Since  separate  networks  for  TOP  SECRET  and 
SECRET  users  will  exist,  with  optimized  conf igurations  for 
their  users,  the  approach  taken  to  combining  them  will  be  as 
follows.  First,  a  combined  optimized  topology  will  be 
developed.  Second,  the  existing  topologies  will  be  con¬ 
nected  with  trunks  approximating  the  optimized  joint  topol¬ 
ogy,  and  the  second  homing  of  dual  homed  subscribers  will  be 
moved  to  switches  of  the  other  (TOP  SECRET  to  SECRET  and 
vice-versa)  type.  This  step  is  roughly  equivalent  to  the 
establishment  of  manual  gates  between  the  TOP  SECRET  and 
SECRET  networks,  with  the  switches  normally  in  the  closed 
position.  The  advantages  of  this  step  are  improved  surviva¬ 
bility,  performance,  and  reliability  for  both  the  TOP  SECRET 
and  SECRET  users,  combined  with  the  retention  of  the 


capability  to  separate  back  to  two  networks  quickly,  with  at 
least  adequate  capability,  if  security  concerns  ever  dictate 
that  step.  IPLIs  will  be  fielded  for  all  classified  sub¬ 
scribers  in  this  stage. 

4  The  fourth  stage  will  connect  the  classified  network  to  the 
unclassified  network  using  automatic,  IPLI-like  gates.  This 
stage  will  proceed  in  two  steps:  (1)  design  of  an  optimized 
topology  and  (2)  placement  of  the  gates  on  links  between  the 
networks  to  approximate  the  optimized  topology. 

5  Additional  stages.  Several  alternatives  are  available  for 
the  final  stage,  when  BLACKER  is  available.  In  one  alterna¬ 
tive,  BLACKER  devices  could  be  put  on  all  hosts  and  the 
automatic  gates  replaced  by  manual  gates  until  confidence 
was  gained  in  the  new  architecture.  This  again  would  permit 
separation  of  the  networks  quickly  if  it  was  felt  necessary. 
In  this  final  stage,  link  encryption  in  the  unclassified 
segment  would  be  upgraded,  as  would  the  level  of  protection 
of  the  switches,  to  conform  with  the  physical  and  crypto¬ 
graphic  security  of  the  classified  segment.  A  second  alter¬ 
native  would  be  to  employ  BLACKER  devices  on  only  classified 
hosts,  and  replace  the  automatic  gates  with  true  multilevel 
secure  gateways.  Tamper-proof  containers,  together  with 
automatic  key  distribution  features  of  the  BLACKER  devices, 
should  greatly  lessen  the  administrative  concerns  associated 
with  the  large  number  of  end-to-end  encryption  devices 
required  with  the  combined  network. 

6.2  Areas  for  Further  Study 

The  level  of  definition  in  [DCA82c]  is  sufficient  to  be  reason¬ 
ably  certain  that  the  summer  review  mentioned  in  Section  1  correctly 
rated  the  options  with  respect  to  security  and  other  operational  fac¬ 
tors.  The  review  found  that  the  chosen  architecture  appears  to  ade¬ 
quately  meet  the  mid-range  needs  of  DDN  subscribers.  It  also  pro¬ 
vides  the  basis  for  reasonable  transition  alternatives  to  longer 
range  DDN  security  architectures  that  support  multi-level  secure 
users,  and  controlled  interaction  between  such  users  and  single-level 
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users  supported  by  BLACKER  E  .  However,  the  review  also  identified  a 
number  of  areas  for  further  study: 


Re lated  Research  and  Development .  There  are  several 
research  and  development  efforts  underway  that  relate  to  DDN 
security*  They  include  BLACKER,  PARAGRAM,  Multinet  Gateway, 
SCC,  MARSHA,  on-board  cryptors,  SCOMP,  and  COS  NFE. 

Suggested  security  research  and  development.  Several  sug¬ 
gested  security  research  and. development  topics  are  related 
to  the  DDN.  They  include  EJ  bypass  characteristics,  EJ 
overhead,  S'3  key  distribution,  routing  and  other  system 
"firewalls,"  use  of  public  data  networks,  cryptographic 
authentication,  distributed  access  control,  E3  and  other 
security  issues  in  upper  protocol  layers,  location  of  vali¬ 
dation  functions,  software  development  practices,  personnel 
countermeasures,  overrun  countermeasures,  gate  management 
alternatives,  mobile  MCs,  MC  trusted  computing  base,  MC  con¬ 
trol  isolation,  use  of  broadcast  satellite  networks,  and 
network  asset  mobility. 

Architecture  refinement.  There  were  several  architecture 
variations  that  the  summer  study  did  not  have  time  to  con¬ 
sider  fully.  They  include  level-of-trust  variations,  equip¬ 
ment  variations,  protocol  and  algorithm  variations,  and  user 
security  level  combinations. 

Policy  and  procedure  issues.  Several  policy  and  procedure 
issues  arose  regarding  the  conduct  of  the  summer  study. 
That  is,  how  might  such  a  study  be  done  better  next  time? 
They  include  alternative  definition  methods  for  both  initial 
generation,  small  variations,  and  modifications  during 
review;  threat  definition  methods,  including  who  defines 
them,  who  knows  them,  and  the  significance  of  perceived 
versus  known  threats;  and  design  constraints,  including 
design  to  cost,  design  to  technical  risk  level,  and  design 
to  threat-counter  level. 


GLOSSARY 


BBN  Bolt  Beranek  and  Newman (  Inc. 

CO I  Community  of  Interest 

CONUS  Continental  United  States 

CSC  Computer  Security  Center 

DCA  Defense  Communications  Agency 

DDN  Defense  Data  Network 

DES  Data  Encryption  Standard 

DoD  Department  of  Defense 

E3  End-to-End  Encryption 

HFEP  Host  Front-End  Processor 

IP  Internet  Protocol 

IPLI  Internet  Private  Line  Interface 

RG  Key  Generator 

MC  Monitoring  Center 

MINET  Movements  Information  Network 

MITRE  The  MITRE  Corporation 

NAC  Network  Access  Component 

RMC  Regional  MC 

SCCS  Software  Configuration  Control  Procedure 

SDC  System  Development  Corporation 

SMC  System  MC 

S/R  MC  SMC  or  RMC 

TAC  Terminal  Access  Controller 

TCP  Transmission  Control  Protocol 

TEP  Terminal  Emulation  Processor 

VIN  WVMCCS  Intercomputer  Network 


REFERENCES 


BBNDCA 

BBN89 

BBN4823 

BBN4968 

BBN4968B 

BBN4974A 

BBN4975 

CSC83 

DCA82a 

DCA82b 

DCA82c 

DCA83a 

DCA83b 

DCA83c 

DCEC82a 

DCEC82b 

FIPS46 


Bolt  Beranek  and  Newman  Inc.  and  the  Defense  Communica¬ 
tions  Agency,  Statement  of  Work  for  Internet  Private  Line 
Interface  (U),  Draft,  revised  25  March  1982,  CONFIDENTIAL. 

Bolt  Beranek  and  Newman  Inc.,  The  Interface  Message  Proces¬ 
sor  Program.  Technical  Information  Report  No.  89,  revised 
December  1978. 

_ ,  Network  Utility  tMC]  Users  Manual. 

_ ,  Requirements  iex  Stage.  1  si  the  ggex  Imak 

IPLI-82-1 ,  April  1982. 

_ ,  Appendix  B  —  Security  Requirements  for  Stage  !  of 

the  Grey  Trunk  Program  (U) ,  Draft,  IPLI-82-11,  7  June  1982, 
SECRET /COMSEC/NOFORN. 

_ ,  Gray  Trunk  Funct iona 1  Design  -  Stage  JL*  Volume  i. 

Revision  1.  IPLI-82-4,  October  1982,  FOR  OFFICIAL  USE  ONLY. 

_ ,  Gray  Trunk  Functional  Design  -  Stage  1_»  Volume  II 

(U),  August  1982,  SECRET /NOFORN. 

DoD  Computer  Security  Center,  Trusted  Computer  System 
Evaluation  Criteria.  Final  Draft,  27  January  1983. 

Defense  Communications  Agency,  Defense  Data  Network  Program 
Plan.  January  1982,  revised  May  1982. 

_ ,  DDN  Security  Architecture,  report  of  ad  hoc  working 

group,  4  November  1982,  FOR  OFFICIAL  USE  ONLY. 

_ ,  Director's  memorandum  to  DUSD  for  C3I,  "Subject: 

Defense  Data  Network  —  Security  Architecture  Options,"  19 
November  1982. 

_ ,  Defense  Data  Network  Management  Engineering  Plan. 

_ ,  Defense  Data  Network  Subscriber  Interface  Guide. 

_ ,  Technical  Assessment  of  the  Application  of  BLACKER 

to  the  Integrated  AUTODIN  System.  12  April  1983. 

This  collection  of  papers  documents  the  topology  design 
analysis. 

This  collection  of  papers  documents  the  survivability 
analysis. 

National  Bureau  of  Standards,  Data  Enervation  Standard. 
Federal  Information  Processing  Standards  Publication  46,  15 
January  1977. 


FIPS81 

FS1025 

FS1026 

FS1027 

Lath82 

NSA82a 

MSA82b 

OPM78 


_ ,  DES  Modes  of  Operation.  _  81,  2  December  1980. 

National  Communications  System,  Interoperability  and  Secu¬ 
rity  Requirements  for  Use  of  the  Data  Encryption  Standard 
in  the  Network  and  Transport  Lavers  of  Data  Communications, 
proposed  Federal  Standard  1025,  1  June  1981. 

_ >  Interoperability  and  Security  Requirements  £o£.  Use 

of  the  Data  Encryption  Standard  in  the  Physical  and  Data 
Link  Layers  of  Data  Communications .  proposed  Federal  Stan¬ 
dard  1026,  21  January  1982. 

General  Services  Administration,  General  Security  Require¬ 
ments  for  Equipment  Using  the  Data  Encryption  Standard. 
Federal  Standard  1027,  14  April  1982. 

Donald  C.  Latham,  "Defense  Data  Network  —  Security  Archi¬ 
tecture  Options,”  Memorandum  to  Director  DCA  and  Director 
NSA,  10  May  1982. 

National  Security  Agency,  Security  Review  of  the  Architec¬ 
tural  Opt  ions  for  the  Defense  Data  Network  (U) ,  October 
1982,  SECRET. 

_ ,  Director's  memorandum  to  DUSD  (C3I),  "Subject: 

Defense  Data  Network  —  Security  Architecture  Options  (U)," 
1  November  1982,  SECRET. 

[Office  of  Personnel  Management,]  United  States  Civil  Ser¬ 
vice  Commission,  Federal  Personnel  Management  Letter  732-7, 
November  14,  1978,  Subject:  Personnel  Security  Program  for 
Positions  Associated  with  Federal  Computer  Systems.  Also 
is  Enclosure  3  to  DCAI  630-230-19. 


READER’S  COMMENT  FORM 
DDN  Subscriber  Security  Guide 


It  is  the  intent  of  the  Defense  Data  Network  Program  Management  Office  to  support  subscribers 
throughout  the  entire  process  of  transitioning  systems  to  the  DDN.  This  Guide  has  been  prepared 
to  assist  subscribers  in  one  phase  of  that  process. 

Comments  concerning  this  Guide  may  be  made  in  the  space  provided  below.  Comments  on  the 
following  topics  are  especially  solicited: 

1.  What  aspects  of  the  Guide  did  you  find  most  helpful? 

2.  What  additions,  deletions,  or  clarifications  would  make  this  Guide  more  useful? 

3.  What  site-specific  problems  do  you  have  that  are  not  adequately  addressed  in  this  Guide? 

Comments: 


Please  fill  in  the  requested  information. 

Position:  _ _ 

Name  (Optional):  _ _ _ 

Address  (Optional): _ 

Status  of  your  system's  current  or  planned  DDN  connectivity: 


Thank  you  for  your  cooperation. 


Defense  Communications  Agency 
ATTN:  DDN  PMO,  Code  B610 
Washington,  DC  20305 


